Splunk の IT Essentials Work を試してみた
2024.07.22Splunk には 2,000以上のAppがありますが、Splunkにそれほど馴染みのない方は多すぎてどれを使ったらいいのか分からなかったりするかと思います。
今回は、インフラのパフォーマンス監視をする観点で役に立つ無料のApp、IT Essentials Work を試してみました。
IT Essentials Work
システム管理者やアプリケーション開発兼運用担当者などは、サービス提供の停止を出来る限り避けるべく、MTTR（Mean Time to Repair） = 平均修復時間を短くする役割を担っているかと思います。
昨今ではIaaSやSaaSなどの利用も深まって、運用する対象が分散化され、パフォーマンス監視においてもツールが分断されてしまっていることが多いと思います。
そらにオンプレミスのシステムの運用も少なからず存在していることも多く、それら全てのログやメトリクスを統合管理したい場合に Splunk を活用することでMTTRを削減することが簡単になります。
IT Essentials Workは取り込んだデータをエンティティ単位でまとめ、グループ化することで、ログとメトリクスの異なるデータを統合的に管理し、全体的なシステムの俯瞰的なビューと詳細なデータへのドリルダウンを可能にするAppとなっています。
IT Essentials Workにはさらに上位の機能があり、こららの機能を有効化するには IT Service Intelligence (ITSI) という有償Appを購入する必要があるので、その点にはご注意ください。
この上位機能の一つに、チューニングされた機械学習機能が組み込まれていることが特徴で、もう一歩高度なログ分析を実現したい場合に、自分で作り込みを必要としない様々なコンテンツを利用することができます。
もちろん、無料AppのIT Essentials Workにも、異なる環境やソースからのログやメトリクスを統合管理するためのたくさんの作り込みいらずのコンテンツやダッシュボードが利用可能なので、今回はそれらの一部を、具体的なユースケースを例に紹介していこうと思います。
尚、ご紹介するユースケース例は、Splunkパートナーが利用できるデモ環境のサンプルデータを使ってご紹介しています。
Appのインストール
Appのインストール方法は、Splunk Cloud、Splunk Enterpriseのどちらのライセンスを利用しているかで異なります。
Splunk Cloud の場合は、通常のSplunkbaseからのインストールではなく、サポートにチケットを発行してインストールする必要があります。
Splunk Enterprise の場合も、環境によってインストール方法の違いがありますので、下記を参照にしてください。
デモ
では、実際にユースケースをもとに IT Essetials Work の画面を紹介していきます。
最初にインストール後の画面の Infrastructure Overview で各システムがグループ化されて、KPIとなるメトリクスを指標にステータスが分かるようになっています。
ユースケースとなるストーリーは以下のようになっています。
- エンドユーザーからWebサービスにログインできないやページがリダイレクトを続けて遷移されないとヘルプデスクに申告があった
- ITインフラチームは迅速な原因調査と関係部署との連携を行う必要がある
まず、Splunk では複数のログを横断してい検索することに長けています。
サーチ画面で、キーワード検索を使って大きく検索します。
キーワードは、複数「OR」演算子でつなげていくことができます。
タイムピッカーは申告があった時間を含む4時間に指定して検索してみます。
左ペーンの抽出されたフィールドから host の統計情報をワンクリックで確認してみると、mysql-02 が最もエラーログが多そうなので、注目してみることができます。
sourcetype (データの種類) で見てみると mysqld となっているので、クリックして検索条件に加えます。
sourcetype を mysqld で絞って検索すると、繰り返しエラーが発生している（binlog で Error Code 28、Disk Spaceのエラー）こと、mysql-02 でのみ発生していることが分かり、原因を絞っていくことができます。
mysql-02 はUnix系のOSにホストされているので、Infrastructure Overview で *nix の
パネルで詳しく見ていきます。
Unix系OSのインスタンスがグループ化されて統計情報が表示されていますが、さらにフィルタで mysql-02 に絞って、さらに詳細をドリルダウンすることができます。
一般的なシステムパフォーマンスを見ることができるダッシュボードが表示されますが、さらに他の観点のダッシュボードに遷移することが可能で、mysql overview に遷移していきます。
こちらの画面では、Disk 使用量のメトリクスを可視化し、その下に mysqld.log のエラーログの総数を可視化しています。
時系列とともに、メトリクスとログの相関関係を一目で見ることができます。
さらに下にスクロールダウンすると、エラーログの一覧が表示されているので、連続して出ているログの因果関係がよく分かります。
エラーの内容をインターネット等で調べるとハードディスクに一時ファイル用の空きスペースが無くなっていることを表しているので、DBチームに容量の拡大をしてインシデントから復旧を行います。
さらに、どうしてこのエラーが発生したのか確認するために他のログソースの分析を進めていきます。
IT Essentials Work には、連携が可能な App があり、IT Essentials Learn を活用して、分析を進めます。
この App では、様々なログソースに対してどのように検索したら良いかのユースケースが確認できるのと、実際のSPLを発行してくれるので、SPLの文法を知らなくてもやりたい分析ができるようになります。
Investigate のタブに遷移すると、左ペーンにログタイプ別に、検索例のパネルが表示されます。
今回の分析対象である Unix and Linux を選択します。
Track Successful logins to a server と Track use of sudo commands on a server で分析すると良さそうなので、それぞれ見ていきます。
Track Successful logins to a server で、Live Data をクリックして、検索します。
（SSH ログインを実施している履歴が分かります。※時系列に矛盾があるのはテスト用データのためです。）
補足ですが Demo Data でどんなログが出るのかも確認できる仕組みになっているので、実際のログがなくてもどんな分析をしたらいいのか学習できるようになっています。
同じく、一つ画面を戻ってから、Track use of sudo commands on a server で、Live Data をクリックして、検索します。
（viコマンドでmy.cnfファイルを編集している履歴が分かります。※時系列に矛盾があるのはテスト用データのためです。）
これで、最終的な根本原因であった設定ファイルの編集が予期せぬ誤った設定となってしまい障害につながったことが分かりました。
まとめ
インフラのパフォーマンス監視に役立つ、Splunkの無料App、IT Essentials Workを使ってみました。
全体の俯瞰から、ドリルダウンがかなりやりやすいと感じました。
また IT Essentials Learn も事前にユースケースを確認して、ログの分析準備が出来るので非常に役に立つのではいかと思います。
